feat: support MCP SDK 2.x alongside 1.x - #33

What

Lifts the mcp<2 cap and makes the proxy work on both MCP SDK 1.x and 2.x.

b861f51 capped the dependency at mcp>=1.8,<2, which keeps installs working but leaves 2.x unsupported. On 2.0 the proxy fails at startup:

ValueError: not enough values to unpack (expected 3, got 2)
  File ".../uc_mcp_proxy/__main__.py", line 180, in run

Because the version range is only capped in the published metadata, uvx uc-mcp-proxy resolves mcp freely for anyone who already has a 2.x-compatible environment, and the failure surfaces as an unhandled ExceptionGroup traceback rather than a diagnosis.

Why it is more than the unpack

SDK 2.0 changed three things this proxy depends on:

The third one is the one that bites silently: inject_meta reached through message.message.root, which no longer exists, so --meta injection would break at runtime rather than at import.

How

src/uc_mcp_proxy/_compat.py resolves the HTTP library by reading it back off mcp.client.streamable_http instead of importing a guessed name:

for name in ("httpx2", "httpx"):
    module = getattr(_sdk_streamable_http, name, None)
    if isinstance(module, ModuleType):
        return module

try: import httpx2 would have been wrong. Both libraries install side by side — httpx2 does not replace httpx, and databricks-sdk still pulls httpx in — so an SDK 1.x user with httpx2 present would get a client built from a library that their SDK never imported. Since the proxy owns the client it hands to streamable_http_client (the design in CLAUDE.md § Error handling), that mismatch surfaces as a type error deep in the SDK's request path instead of at import time. Asking the SDK which module it bound is the only answer that cannot drift.

• The dropped third yield element is absorbed by a starred unpack — it was bound to _get_session_id and never used.
• bridge() / copy_stream() now take structural stream protocols, because 1.x hands out anyio memory streams and 2.0 hands out its own context-carrying wrappers. Naming either concrete class type-checks against one SDK and fails on the other.
• No direct import httpx remains for anything crossing the SDK boundary; those go through the shim so every request, response and transport object comes from the library the installed SDK actually uses.

The boundary matters in both directions. Rebasing onto the PAT-exchange merge (#27) surfaced this: token_exchange.py builds its own synchronous httpx.Client for the RFC 8693 call and never hands it to the SDK, so it correctly keeps importing httpx directly. Blanket-swapping the test file's import broke seven exchange tests — a MockTransport from the other library is silently not used, and the exchange then tried to reach the real network:

uc-mcp-proxy: could not reach the workspace token endpoint.
  endpoint: https://test-workspace.cloud.databricks.com/oidc/v1/token

test_http_errors_e2e.py now imports both deliberately: httpx (shim) for SDK-boundary objects, exchange_httpx (plain) for the exchange transport. CLAUDE.md documents which side a new import belongs on.

tests/support.py builds messages by validating a raw wire payload through the SDK's own schema (TypeAdapter(JSONRPCMessage)), which accepts both the root-model and union shapes and keeps the JSON that actually goes on the wire as the source of truth.

CI gains a test-sdk-majors job. The lockfile only ever proves whichever major it happens to hold, so each supported major is resolved and exercised explicitly (unit tests + mypy). Without it this regresses the moment the lock moves.

Verification

Run against both mcp==1.29.0 and mcp==2.0.0:

• make test — 411 passed
• make check — ruff lint, ruff format, mypy strict, all clean

Plus a live end-to-end run outside the suite: the real uc-mcp-proxy subprocess against a real MCP Streamable HTTP server over a real localhost socket, with real DatabricksAuth header injection — initialize, tools/list, and a tools/call round-trip all verified on both SDK majors. Nothing mocked.

The existing test_http_errors_e2e.py suite is what caught the SessionMessage change: 28 tests went red on 2.0 before the fix, which is why this is not just a one-line unpack patch.

Rebased onto 1f57152 (post-#27).

Notes for review

• Two commits, separable. 0f2fa1e (test:) is a drive-by and unrelated to SDK 2.0 — it carries SystemRoot/SystemDrive into the subprocess test's env. That env is built from scratch so a developer's real DATABRICKS_* cannot reach the child, but on Windows that also drops SystemRoot, and winsock then fails to initialize: the child dies importing asyncio's proactor loop with WinError 10106 before reaching the code under test. No effect on Linux CI. Happy to drop it into its own PR if you'd rather keep this one focused.
• httpx is left in dependencies. It is still correct for SDK 1.x, and on 2.x httpx2 arrives transitively through mcp. A static dep list cannot express "httpx if mcp<2 else httpx2".
• Type annotations are checked against the httpx stubs, which describe httpx2 accurately for every name used here. The one place the two genuinely cannot be reconciled statically — passing the client into the SDK — is an explicit cast with a comment.
• Unrelated pre-existing flake, not addressed: test_proxy_process_exits_on_401_with_stdin_still_open is timing-sensitive and fails intermittently on slow filesystems, taking the _report fallback path or exceeding its 30s budget. I reproduced it on unmodified master with mcp==1.29.0, so it predates this change and I left it alone.